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TRW  has  recently  completed  a  research  project  spon-  The  foundation  technology  for  the  PTDE's  generic 
sored  by  the  USAF's  Electronics  Systems  Division  command  center  approach  was  developed  on  ESD's 

(ESD)  to  support  the  development  of  the  Pilot  Com-  Command  Center  Processing  and  Display  System  Re¬ 
mand  Center  (PCC)  for  SDI.  The  PCC  is  a  facility  that  placement  (CCPDS-R)  program  starting  in  1986.  Tlie 

will  be  used  by  the  USAF  to  develop  the  system  level  CCPDS-R  prograii*  mcludes  the  replacement  of  all  the 

requirements  for  the  Communication,  Command  and  ADPE  and  C^  software  in  a  set  of  related,  existing 

Control  (C^)  elements  of  SDI  with  particular  emphasis  command  centers.  The  requirement  to  simultaneously 

on  determining  the  role  of  the  human  in  control  by  develop  software  for  multiple  command  centers  created 

means  of  experimentation.  TRW’s  role  in  this  project  extra  incentives  to  incorporate  reusable  components 

was  to  evaluate  the  feasibility  of  reusing  the  software  and  development  techniques  in  the  design  process.  The 

architecture  developed  on  an  earlier  ESD  sponsored  emergence  of  Ada  as  a  viable  programming  language 

....iiiiiiand  center  development  project  for  this  applica-  with  its  support  of  concurrency  and  software  engineer- 

tion.  The  PCC  Testbed  Development  Environment  ing  enab'ed  us  to  implement  reliable,  reusable  Network 

(PTDE)  which  is  the  project's  primary  product  provides  Architecture  Services  (NAS)  software  [Royce  1989]  as 

the  capability  to  rapidly  implement  and  integrate  proto-  the  infrastructure  for  all  the  commaid  centers  sup- 

type  C^  system  application  software  (including  mes-  ported  by  CCPDS-R.  This  software  is  currently  being 

sage  sets,  databases,  mission  algorithms,  and  interac-  reused  on  other  TRW  command  center  development 

tivc  displays)  and  to  easily  migrate  the  prototype  soft-  projects.  Given  NAS  as  a  foundation,  the  CCPDS-R 

ware  into  a  complete  C^  system  testbed  suiUble  for  program  developed  tools  that  it  used  to  automatically 

conducting  realtime  experiments.  The  experience  generate  a  substantial  portion  of  its  newly  developed 

gained  in  developing  and  using  th^generic  command  source  code.  These  tools  and  techniques  were  built 

center  tools  and  techniques  that  werfe  used  can  be  ap-  specifically  for  the  CCPDS-R  program  and  qre  not  de- 

plicd  to  future  comn^and  center  development  programs  signed  to  be  generally  reusable.  However,  the  basic 

to  reduce  system  development  costls  and  schedules.  ideas  behind  them  can  be  used  as  the  basis  for  develop- 

This  paper  summarizes  the  PTDE  des^n  and  develop-  •r'S  ^  integrated  generic  command  center  capability 

ment  process  with  supporting  rationale.^ It  also  includes  which  promises  to  greatly  enhance  expected  productiv- 

some  "lessons  learned"  and  recommenijations  for  en-  '*7  o"  future  command  center  development  projects 

hancing  the  development  process  on  future  C^  devel-  [Grauling  1990]. 

opment  efforts. 

The  effectiveness  of  the  NAS  framework  and  the  use  of 
automated  code  generation  have  been  major  contrib¬ 
utors  to  the  success  enjoyed  by  the  CCPDS-R  program. 
These  principles  and  techniques  can  be  applied  on  other 
command  center  development  activities  by  using  them 
as  a  basis  for  designing  generic  C^  system  application 
components  that  execute  within  the  NAS  provided 
framework.  The  CCPDS-R  implementation  was  opti¬ 
mized  for  performance  in  CCPDS-R's  target  environ¬ 
ment  (DEC  VAX/VMS,  1987  vintage  display  technol¬ 
ogy,  etc.).  Broadening  the  applicability  of  CCPDS-R 
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Figure  1;  Liystem  Software  Architecture 


technology  requires  modifying  the  implementation  to 
optimize  for  portability  and  adherence  to  industry  stan¬ 
dards.  This  would  allow  the  benefits  of  the  CCPDS-R 
architecture  while  providing  the  capability  to  take  ad¬ 
vantage  of  emerging  commercial  off  the  shelf  technol¬ 
ogy  such  as  processors,  workstations  and  standard 
software  interfaces.  The  development  of  the  PTDE 
provided  an  excellent  opportunity  to  identify  and  im¬ 
plement  these  modifications.  The  remainder  of  this 
section  is  a  brief  synopsis  of  NAS  and  CCPDS-R's 
software  development  approach  as  background  for 
readers  who  are  unfamiliar  with  them. 

NAS  Fundamentals.  NAS  is  an  outgrowth  of  an  Inter¬ 
nal  Research  and  Development  (TR&D)  project  to  de¬ 
termine  the  applicability  of  Ada  to  system  develop¬ 
ment  which  was  started  in  1985.  The  IR&D's  fust 
output  was  a  product  called  InterTask  Communication 
(ITC).  ITC  provides  a  mechanism  which  enables  Ada 
tasks  to  perform  logical  I/O  amongst  themselves  with¬ 
out  explicit  synchronization  or  knowledge  of  the  under¬ 
lying  hardware.  Once  ITC  was  in  place,  it  became  ap¬ 
parent  that  we  could  layer  additional  reusable  executive 
software  components  on  top  of  ITC  to  create  an  inte¬ 
grated  development  and  runtime  environment  for  im¬ 
plementing  distributed  applications  (Figure  1).  ITC 


and  the  executive  layer  above  it  were  collected  into  a 
product  called  Network  Architecture  Services  (NAS)  to 
provide  a  complete  executive  framework  for  building 
complex  applications  on  a  distributed  computer  system. 
The  functions  performed  or  supported  by  NAS  include: 
system  initialization,  fault  detection,  reconfiguration, 
error  handling,  and  interactive  network  health  and  sta¬ 
tus  monitoring.  NAS  is  currently  in  use  successfully  on 
CCPDS-R  [Royce  1989]. 

ITC  is  the  foundation  capability  upon  which  NAS  has 
been  built.  The  two  critical  communication  abstrac¬ 
tions  defined  by  FTC  are  called  sockets  and  circuits.  A 
socket  is  a  virtual  I/O  channel  that  an  application  task 
uses  to  send  and/or  receive  messages.  Application 
tasks  can  create  and  delete  sockets  at  runtime  using 
ITC  provided  services.  Application  tasks  communicate 
by  establishing  connections  among  their  sockets  called 
circuits.  Once  a  task  has  created  its  sockets  and  cir¬ 
cuits,  it  is  able  to  perform  logical  I/O  with  other  tasks 
by  reading  messages  from  its  input  sockets  and  writing 
messages  to  its  output  sockets.  ITC  provides  the  mes¬ 
sage  buffering  and  synchronization  necessary  to  allow 
both  the  sending  and  receiving  tasks  to  execute  without 
waiting.  A  system  consists  of  independently  executing 


(A)  TYPICAL  APPLICATION  PROGRAM 
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Figure  2:  Standard  Application  Program  Suoiclure 


tasks  whose  only  stimuli  are  messages  which  they  read 
and  whose  only  outputs  are  messages  which  they  write. 

Designing  a  system  under  ITC  requires  partitioning  the 
application  into  software  modules  that  conform  to  this 
model.  We  call  this  design  methodology  "message 
based  design".  Message  based  design  provides  com¬ 
plete  encapsulation  of  the  multiprocessor  architecture 
details  within  ITC  (i.e.,  application  tasks  send  and 
receive  messages  of  predefined  types  without  any 
knowledge  of  the  location  of  the  receivers  or  senders). 
The  advantages  of  this  approach  include: 

•  It  enforces  hardware  independent  design  by 
requiring  the  exclusive  use  of  logical  input/output. 
Hardware  independence  contributes  to  the  overall 
flexibility  of  the  software  design. 

•  It  promotes  a  cohesive  and  modular  software  de¬ 
sign  by  requiring  early  formal  definition  of  task- 
to-ta.sk  interfaces  and  disallowing  common 
coupling  among  tasks. 

•  It  reduces  Ada  training  costs  and  development  risk 
by  encapsulating  Ada  tasking  within  ITC.  De¬ 
signers  can  implement  multitasking  applications 
with  all  the  benefits  of  using  Ada  (e.g.,  packages. 


strong  typing)  without  explicitly  using  Ada’s  rel¬ 
atively  complex  tasking  mechanism. 

•  It  reduces  synchronization  problems  among  com¬ 
municating  application  tasks.  Sending  tasks  never 
have  to  synchronize  with  receiving  tasks  to  ac¬ 
complish  communication.  They  simply  send. 
FTC  buffers  the  messages  and  delivers  them  to  the 
receiving  tasks  upon  request.  The  synchronization 
required  is  accomplished  using  Ada  tasking  within 
ITC. 

Although  ITC  provides  a  sufficient  capability  for  im¬ 
plementing  message  based  systems,  it  is  possible  to 
standardize  the  structure  of  ITC  based  applications 
software.  The  standard  task  executive  handles  certain 
complex  system  issues  such  as  system  fault  detection, 
error  handling,  and  system  reconfiguration  in  a  manner 
that  is  as  transparent  to  applications  as  possible. 

Figure  2  (A)  is  a  schematic  representation  of  a  typical 
NAS  based  standard  application  program.  NAS  stan¬ 
dardizes  the  implementation  of  executive  functions  by 
including  NAS  provided  control  processing  in  every 
standard  application  program.  This  processing  behaves 
as  if  it  were  performed  by  an  included  program  con- 


trollcr  task  as  illustrated.  The  program  control  task 
performs  processing  that  is  common  to  all  NAS  appli¬ 
cation  programs  such  as  process  synchronization  upon 
initial  program  load,  ITC  network  login,  standard  error 
handling,  status  reporting,  and  monitoring  the  health 
and  status  of  the  application  tasks  contained  in  the 
program. 

The  standard  application  task.  Figure  2  (B),  is  the  basic 
processing  module  for  a  NAS  based  system.  It  consists 
of  the  standard  executive  shell,  standard  control  mes¬ 
sage  processing,  and  application  specific  message 
handling  and  control  procedures  shown  in  Figure  2  (C). 
The  executive  in  each  application  task  detects  when 
ITC  has  a  message  to  deliver  to  one  of  its  input  sockets 
and  determines  which  socket  has  the  next  message  to 
read.  For  each  message  arriving  on  an  application 
input  socket,  the  task  shell  executes  the  application 
message  handling  procedure  associated  with  that 
socket.  The  application  message  handling  procedure 
then  reads  and  processes  the  message.  This  processing 
generally  includes  producing  output  such  as  writing  one 
or  more  messages  to  one  or  more  of  its  output  sockets 
or  performing  external  I/O.  This  is  how  the  ta.sk 
accomplishes  useful  work. 

Incoming  control  messages  are  handled  by  NAS.  Cer¬ 
tain  control  messages  are  handled  in  a  fashion  that  is 
transparent  to  the  application  task.  The  control  mes¬ 
sage  that  requests  a  standard  task  level  status  informa¬ 
tion  is  an  example  of  a  transparent  control  message. 
These  messages  provide  the  mechanism  whereby  the 
program  controller  can  gather  performance  data  or  de¬ 
tect  failures  (i.e.,  a  response  time-out).  NAS's  control 
message  mechanism  is  also  extendable  to  allow  appli¬ 
cation  specific  control  procedures.  This  feature  is  used 
to  allow  applications  to  issue  network  wide  commands 
(for  example  to  command  a  network  reconfiguration  or 
a  database  reset)  without  requiring  explicit  knowledge 
of  the  network's  structure.  In  addition  to  providing  the 
top  level  abstraction  for  the  implementation  of  applica¬ 
tion  components,  the  existence  of  standardized  appli¬ 
cation  components  provided  a  framework  to  include 
support  functions  such  as  standardized  error  handling, 
performance  monitoring  and  logging,  interactive  net¬ 
work  control,  and  system  reconfiguration  in  all  NAS 
based  systems.  The  standard  structure  of  NAS  based 
systems  makes  it  possible  to  automate  portions  of  the 
software  development  process.  One  of  the  first  tools  in 
this  category  was  the  Software  Architecture  Skeleton 
(SAS)  Builder  tool.  This  tool  allows  one  to  build  a  text 
file  description  of  an  entire  NAS  network.  The  tool 
processes  the  text  file  and  produces  all  the  source  code 


required  to  build  the  network  out  of  the  generic  NAS 
application  components. 

CCPDS-R  Software  Development  Approach.  In  addi¬ 
tion  to  using  NAS,  the  CCPDS-R  project  used  a  new 
approach  to  the  software  development  process  de¬ 
scribed  in  [Springman  1989]  and  [Royce  1990].  This 
approach  uses  incremental  builds,  top  down  integration, 
and  tools  which  automatically  generate  a  substantial 
fraction  of  the  deliverable  Ada  source  code.  Tre  tr.ois 
were  developed  specifically  for  the  CCPDS-R  project 
in  an  ad  hoc  fashion  (i.e.,  they  were  invented  and  im¬ 
plemented  by  programmers  for  their  own  purposes  to 
aid  configuration  management  and  source  code  genera¬ 
tion  wherever  it  made  sense).  Our  approach  to  demon¬ 
strating  the  feasibility  of  reusing  CCPDS-R  technology 
in  the  PCC  included  using  NAS  and  its  associated  SAS 
builder  tool  "as  is",  reusing  CCPDS-R  application 
components  wherever  appropriate,  replacing  custom 
CCPDS-R  components  with  equivalent  Commercial 
Off  the  Shelf  (COTS)  technology  where  possible,  and 
enhancing  the  ad  hoc  code  generating  tools  to  make 
them  more  effective  for  use  in  the  PTDE. 

PTDE  Design  Overview 

The  PTDE  consists  of  the  two  major  components  illus¬ 
trated  in  Figure  3.  The  C^  system  development  envi¬ 
ronment  is  a  host  facility  with  ADPE  resources  and 
software  development  tools  that  can  be  used  to  build 
working  prototypes  of  C^  systems.  The  C^  system 
evaluation  environment  provides  the  ADPE  resources 
and  application  software  necessary  to  conduct  com¬ 
mand  center  experiments  with  human  controllers  per¬ 
forming  realistic  command  center  tasks  in  a  realisti¬ 
cally  simulated  command  center  environment.  The  key 
attribute  of  the  C^  system  development  environment  is 
its  ability  to  support  all  aspects  of  rapid  command  cen¬ 
ter  development.  This  includes  facilities  for  rapidly 
building  display  prototypes,  developing  the  software 
required  to  handle  external  message  sets  and  the  vari¬ 
ous  types  of  format  conversion  that  they  require,  simu¬ 
lating  external  system  components  (e.g..  external 
weapon  and  sensor  systems),  and  developing  the  gen¬ 
eral  purpose  software  required  to  implement  mission 
specific  algorithm  processing.  The  existing  CCPDS-R 
development  system  was  the  starting  point  for  the  de¬ 
velopment  of  this  portion  of  the  PTDE.  The  key  at¬ 
tribute  for  the  C^  system  evaluation  environment  is  its 
realism.  Realism  comes  from  providing  a  simulated 
command  center  environment  that  has  adequate  inter¬ 
active  response  time  performance  and  uses  simulation 
techniques  with  sufficient  fidelity  to  properly  exercise 
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the  humans  in  control.  Another  important  feature  of 
the  system  evaluation  environment  is  its  ability  to 
gather  the  measurable  performance  information  re¬ 
quired  to  quantitatively  assess  the  operation  of  the  ex¬ 
perimental  command  centers.  The  CCPDS-R  runtime 
environment  with  NAS  and  its  associated  performance 
measurement  facilities  were  the  starting  point  for  the 
development  of  this  capability. 

The  PTDE  development  process  consisted  primarily  of 
the  integration  of  existing  software  components  with 
very  little  new  software  development.  Its  design  is 
based  on  the  software  engineering  principles  and  sup¬ 
porting  reusable  components  that  were  developed  on 
the  CCPDS-R  program  and  other  IR&D  projects,  and 
the  use  of  Commercial  Off  the  Shelf  (COTS)  products. 
We  used  an  incremental  development  approach  consist¬ 
ing  of  three  builds.  The  first  build  started  with  a  base¬ 
line  system  taken  directly  from  the  CCPDS-R  devel¬ 
opment  facility.  We  modified  it  to  remove  certain  ca¬ 
pabilities  that  are  not  necessary  in  the  PCC  environ¬ 
ment.  These  capabilities  include  the  primary/shadow 
threads  that  CCPDS-R  uses  to  provide  hardware  fault 


tolerance  and  the  Test/Real  separation  that  the 
CCPDS-R  program  uses  to  allow  test  mode  operation 
on  the  real  system.  The  implementation  of  these  ca¬ 
pabilities  is  transparent  to  most  application  software  in 
a  NAS  based  command  center  because  of  NAS's  built- 
in  support  for  these  functions.  The  performance  impact 
of  having  these  capabilities  are  negligible  in  any 
realistic  command  center  application  because  they  use 
redundant  processing  resources.  The  second  build 
consisted  of  replacing  the  display  and  database 
management  systems  that  were  developed  specifically 
for  CCPDS-R  with  COTS  software  products  (e.g.,  a 
commercially  available  relational  DBMS  and  a 
commercially  available  X-windows  implementation). 
The  motivation  for  this  approach  was  to  trade  per¬ 
formance  for  flexibility  and  portability.  Since  the 
PTDE  is  an  experimental  facility  whose  mission  is  de¬ 
velop  C^  system  requirements,  it  is  more  important  to 
be  able  to  rapidly  implement  systems  than  to  squeeze 
the  most  performance  out  ADPE  hardware.  The  third 
build  was  the  formal  demonstration  of  the  PTDE’s  abil¬ 
ity  to  accommodate  the  transition  from  the  CCPDS-R 
application  to  Space  Defense  Systems  (SDS)  applica- 
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lions.  The  primary  objective  of  the  third  build  was  to 
go  through  the  process  of  installing  an  SDS  specific  al¬ 
gorithm  involving  weapons  and  sensors.  In  the  process, 
we  measured  the  productivity  characteristics  of  the 
PTDE's  system  development  environmen*.  The 
remainder  of  this  section  provides  descriptions  of  the 
major  components  of  the  PTDE  with  emphasis  on  the 
tradeoffs  that  had  to  be  made  among  various  software 
quality  attributes  such  as  portability,  performance  char¬ 
acteristics,  usability  flexibility.  It  is  organized  in 
terms  of  the  basic  functions  that  are  common  to  all 
systems:  external  message  interfaces,  database  man¬ 
agement.  mission  algorithm  processing,  and  user 
interfaces. 

External  Representation  Management.  One  of  the 
fundamental  capabilities  of  a  system  is  its  ability  to 
receive  incoming  mes.sage  traffic,  convert  them  from 
their  external  format  to  a  variety  of  internal  formats  so 
they  may  be  used  by  processing  and  display  application 
software,  and  to  generate  outbound  messages  in  an 
agreed  upon  external  format.  Real  world  command 
centers  generally  deal  with  hundreds  of  different  types 
of  messages  and  a  small  number  of  different  external 
communication  protocols.  The  high  leverage  area  is 
clearly  in  the  message  formatting  portion  of  the  com¬ 
munication  proce.ssing.  The  CCPDS-R  program  devel¬ 
oped  an  automated  system  for  producing  format  con¬ 
version  procedures.  Tliis  system  involves  capturing  the 
external  format  definition  information  usually  provided 
in  an  external  Interface  Control  Document  (ICD)  in  a 
text  file  and  using  a  tool  to  parse  this  text  file  and 


automatically  generate  key  software  products.  The  text 
file  serves  as  the  source  file  for  automatically  generat¬ 
ing  the  Ada  source  code  and  the  other  internal 
representations  that  are  required  in  a  typical  system 
shown  in  Figure  4.  The  list  of  products  produced  by 
the  Communication  Message  Tool  (C.MT)  for  a  typical 
input  message  type  consists  of  the  following  items: 

*  Message  Validation  Procedures.  Every  external 
message  that  enters  the  system  must  be  picked 
apart  on  a  field  by  field  basis.  Each  field  must  be 
checked  for  violations  of  range  of  value  con¬ 
straints  that  are  specified  in  the  ICD  prior  to  con¬ 
version  into  its  internal  format.  The  message  tool 
produces  the  source  code  for  an  Ada  procedure  to 
perform  this  processing  for  each  input  message 
type.  In  some  cases,  special  ad  hoc  processing 
may  be  required  as  specified  in  the  ICD.  The 
message  tool  also  provides  the  hooks  to  add  this 
type  of  application  specific  field  validation  logic 
to  the  format  conversion  procedure  if  requ'med. 

•  Ada  Representation  Specifications.  In  the 
CCPDS-R  software  architecture,  external  mes¬ 
sages  enter  the  system  through  communication 
processing  tasks  that  perform  protocol  processing 
and  produce  an  input  datagram  for  each  arriving 
external  message.  The  bit  by  bit  description  of 
this  format  is  defined  in  the  ICD.  The  Ada  pro¬ 
grams  that  process  these  messages  need  an  Ada 
representation  clause  to  locate  individual  fields 
within  the  input  message  datagram.  One  of  the 
first  steps  in  the  processing  of  a  message  is  its 
conversion  from  an  array  of  bytes  to  an  Ada  ob- 


ject  with  an  associated  internal  Ada  record  type. 
The  type  specification  for  the  internal  Ada  object 
representation  of  each  input  message  type  is 
automatically  produced  by  the  message  tool  based 
on  information  extracted  from  the  ICD  and  incor¬ 
porated  in  the  message  tool's  input  text  file. 

•  Human  Readable  Output  Formatting  Procedures. 
CCPDS-R  allows  the  user  to  print  any  external 
message  in  human  readable  form  on  a  suitable 
output  device  (such  as  a  line  printer).  The 
CCPDS-R  message  tool  can  automatically  gener¬ 
ate  the  Ada  source  code  for  a  procedure  to  convert 
the  internal  representation  of  an  external  message 
into  its  human  readable  form.  It  does  so  based  on 
the  information  in  the  CMT  source  text  file  which 
contains  field  definitions  and  other  related  infor¬ 
mation  such  as  the  agreed  upon  field  labels  and 
mnemonics. 

•  External  Message  Simulator  Display  Forms. 
CCPDS-R  has  a  built  in  external  message  simula¬ 
tion  capability  that  allows  the  operator  to  con¬ 
struct  and  subsequently  inject  externally  formatted 
test  messages.  This  capability  uses  an  on-line 
database  of  form  descriptions  to  support  the 
operator  interface  to  the  external  message  genera¬ 
tion  capability.  The  CMT  automatically  popu¬ 
lates  this  database  using  information  contained  in 
its  source  text  file. 

•  External  Message  Simulator  Control  Information. 
This  item  is  also  related  to  the  external  message 
simulation  capability.  The  internal  simulation  ca¬ 
pability  uses  an  on-line  database  to  control  last 
minute  message  formatting  details  such  as  insert¬ 
ing  the  correct  time  tags  in  simulated  external 
messages.  The  CMT  automatically  populates  this 
database  using  information  contained  in  its  source 
text  file. 

•  COTS  DBMS  Schema  Definition.  C-^  systems 
routinely  log  incoming  and  outgoing  messages.  If 
a  COTS  DBMS  is  used  to  implement  this  func¬ 
tion,  the  ability  to  easily  perform  on-line  data  re¬ 
view  and  reduction  is  provided  by  the  COTS 
product  The  information  necessary  to  automat¬ 
ically  generate  the  SQL  data  definition  statements 
which  define  a  table  for  each  type  of  external 
message  already  exists  in  the  CMTs  source  text 
file.  Adding  this  type  of  support  required  a  minor 
modification  to  the  existing  CCPDS-R  CMT. 

The  key  advantage  provided  by  CMT  is  its  consistency. 

When  the  external  definition  of  a  given  message  type 

changes,  a  single  update  of  the  input  source  text  and 

subsequent  rerun  of  the  tool  will  produce  a  complete 


and  consistent  set  of  modified  source  code  for  all  af¬ 
fected  software  components  and  databases.  The  ab¬ 
sence  of  this  typie  of  tool  in  the  PTDE  would  mean  that 
PTDE  users  would  have  to  manually  create  all  the 
above  mentioned  source  code  for  each  new  message 
type  that  is  added  to  the  PTDE's  repertoire  of  supported 
messages.  The  CCPDS-R  CMT  is  adequate  for 
CCPDS-R’s  purposes,  but  it  needed  enhancement  in  the 
form  of  a  more  user  friendly  front  end  to  make  it  more 
suitable  for  use  in  the  PTDE.  In  its  original  state,  CMT 
did  no  error  checking  of  its  input  source  file.  Key¬ 
punch  errors  or  failure  to  adhere  to  the  rigid  flat  file 
format  could  cause  the  CMT  to  crash  (i.e.,  raise  an  un¬ 
handled  exception,  at  run  time).  This  front  end  helps 
the  user  create  CMT  input  by  providing  a  form  filling 
type  of  interface  which  also  performs  on-line  data  in¬ 
tegrity  checking.  It  makes  the  process  of  creating  new 
message  types  and  updating  old  message  types  more 
productive  for  the  occasional  user. 

Database  Management.  In  our  generic  command  cen¬ 
ter  model,  external  messages  arrive,  popuhte  a 
database  and  cause  mission  algorithms  to  run.  Mission 
algorithms  generate  processed  information  which  is 
also  stored  in  the  database.  They  can  also  cause  opera¬ 
tor  alarms  which  will  generally  cause  the  C^  system 
operators  to  take  some  action.  Operators  interact  with 
the  database  through  their  workstations  under  the  con¬ 
trol  of  user  interaction  software.  The  database  man¬ 
agement  function  provides  the  storage,  distribution,  and 
integrity  protection  of  the  displayable  database.  There 
are  several  different  implementation  strategies  for  this 
important  function.  The  choice  of  a  design  approach 
involves  the  tradeoffs  among  attributes  such  as  devel¬ 
opment  cost,  performance,  and  flexibility.  The 
CCPDS-R  program  was  performance  driven  with  a  well 
known,  stable  list  of  required  displayable  data  items.  It 
therefore  selected  a  high  efficiency  memory  resident 
database  approach  over  a  COTS  DBMS  based  ap¬ 
proach.  In  CCPDS-R,  there  was  a  single  master 
database  which  was  the  recipient  of  all  messages  and 
algorithm  results.  The  CCPDS-R  master  database  ac¬ 
tively  distributed  displayable  database  updates  to  each 
of  the  workstations  which  were  maintaining  a  local 
memory  resident  copy  of  the  master  database.  Auto¬ 
matic  updates  to  users'  displays  were  triggered  by 
database  distribution  events.  This  approach  ensured 
display  consistency  across  the  complete  set  of  worksta¬ 
tions  that  were  serviced  by  the  system.  These  prop¬ 
erties  were  explicitly  specified  in  the  CCPDS-R  system 
specification. 


TO  WORKSTATIONS 


Figure  5;  Typical  Mission  Processing  SAS  Structure 


The  requirements  are  quite  different  for  the  PTDE.  In 
particular,  flexibility  and  ease  of  change  are  more  im¬ 
portant  than  performance,  provided  the  interactive  re¬ 
sponse  time  is  realistic  for  the  purposes  of  determining 
operator  workload.  We  therefore  decided  to  replace  the 
CCPDS-R  database  management  system  with  a  func¬ 
tionally  equivalent  COTS  DBMS  based  implementa¬ 
tion.  This  meant  replacing  the  m.a.ster  and  slave 
database  managers  in  the  CCPDS-R  implementation 
with  a  general  purpose  database  server.  Under  this 
approach,  application  processes  that  create  displayable 
data  store  their  data  in  tables  managed  by  the  server 
while  application  processes  requiring  access  to  data 
throughout  the  network  can  log  into  the  server  as 
clients.  The  database  server  handles  all  the  processing 
required  to  ensure  data  integrity.  The  major  advantages 
of  a  COTS  based  approach  are  the  additional  facilities 
that  it  provides.  These  include  forms  editors,  interac¬ 
tive  user  query  support,  report  writers,  security  fea¬ 
tures,  and  support  for  data  archiving  and  recovery. 
Under  the  original  CCPDS-R  approach,  all  access  to 
the  display  database  was  performed  via  procedure  calls. 
The  PTDE’s  system  has  the  same  interface  with  access 
to  the  underlying  database  system  completely  encapsu¬ 
lated  in  the  bodies  of  the  access  procedures.  Support 
for  data  definition  is  built  into  the  CMT.  The  amount 


of  source  coding  required  to  implement  the  access  pro¬ 
cedures  in  the  body  parts  is  roughly  the  same  in  both 
approaches.  In  the  CCPDS-R  system,  this  coding  is 
done  in  Ada  whereas  the  COTS  DBMS  based  approach 
uses  vendor  provided  bindings  to  access  procedures  or 
SQL  module  language. 

yis'ion  Proersring  In  the  generic  command  center 
model,  the  mission  processing  functional  area  contains 
the  algorithms  that  process  incoming  information  and 
send  displayable  results  to  the  database  management 
system.  These  results  are  ultimately  used  by  the  inter¬ 
active  users  as  decision  aids.  Since  mission  processing 
is  application  unique  by  definition,  ir  is  the  func-nrinl 
area  of  a  command  center  that  is  least  likely  to  benefit 
from  the  use  of  generic  command  center  design  tech¬ 
niques.  We  applied  some  general  guidelines  for  pack¬ 
aging  mission  processing  into  NAS  compatible  net¬ 
works  to  create  the  mission  processing  portion  of  the 
Version  3  software  architecture  skeleton.  Figure  5. 

The  main  objective  in  the  design  of  the  Version  3  mis¬ 
sion  processing  software  architecture  skeleton  is  to 
provide  a  flexible  structure  into  which  mission  process¬ 
ing  algorithms  could  easily  be  inserted.  In  particular, 
the  ability  to  spread  computationally  intense  processing 


over  multiple  processors  in  order  to  ensure  that  cur¬ 
rently  unspecified  performance  requirements  could  be 
satisfied  by  simply  adding  processors  without  major 
software  modifications.  Figure  5  illustrates  the  general 
structure  of  the  mission  processing  portion  of  the  Ver¬ 
sion  3  SAS.  This  structure  features  a  top  level  con¬ 
troller  task  which  handles  all  input  events  (such  as  an 
incoming  sensor  message  or  an  operator  entered  control 
command)  and  controls  the  execution  of  a  collection  of 
event  handler  tasks  by  routing  messages  to  the  appro¬ 
priate  event  handler  task  as  a  function  of  the  incoming 
message  type  and  the  current  state  of  the  system.  The 
basic  idea  behind  this  task  structure  is  to  provide  a  task 
framework  that  allows  the  software  architect  to  allocate 
processing  associated  with  specific  weapon  and  sensor 
systems  to  separate  tasks.  These  separate  tasks  could 
then  be  executed  on  different  processors. 

In  this  architecture,  the  Mission  Processing  Executive 
task  functions  primarily  as  a  top  level  problem  solver. 
It  implements  top  level  algorithms  (i.e.,  algorithms 
whose  logic  depends  on  the  results  generated  by 
multiple  weapon  or  sensor  system  models).  It  also  has 
the  capability  to  initiate  and  control  concurrent 
"'•'x.'essing  functions.  This  capability  enables  it  to 
function  as  an  ADPE  processing  load  leveler.  For 
example,  it  is  possible  to  replicate  a  given  type  of  event 
handler  task  on  multiple  processors  to  allow  algorithms 
with  high  CPU  resource  demands  to  be  broken  up  and 
spread  over  multiple  processors  under  the  Mission 
Processing  Executive's  control.  Under  the  message 
based  design  paradigm,  all  algorithm  processing  is 
triggered  by  incoming  message  traffic.  There  are  three 
types  of  mission  processing  trigger  messages:  external 
communication  message  receipt,  internal  timer  events, 
and  interactive  user  service  requests.  In  general,  any  of 
these  events  will  cau;:  the  Mission  Processing 
Executive  (MPE)  task  to  perform  some  form  of 
algorithm  processing.  Throughout  this  paper,  the  term 
"algorithm  processing"  refers  to  the  processing 
performed  in  response  to  any  of  these  external  events. 

Algorithm  processi  'g  normally  results  in  an  update  to 
the  dynamic  database  which  is  used  to  populate  user 
displays  and/or  generate  outbound  messages.  MPE 
performs  part  of  this  processing  directly  (i.e..  within  its 
own  input  message  handling  procedures)  and  it  may 
also  perform  part  of  it  concurrently  by  sending  control 
messages  to  one  or  more  of  the  event  handler  illustrated 
in  Figure  5.  The  relationship  between  MCE  and  the 
other  application  tasks  that  it  controls  is  similar  to  the 
client/server  model  commonly  used  in  COTS  DBMS 
and  workstation  products,  tailored  as  appropriate  to 
operate  in  the  concurrent  programming  model  provided 


by  NAS.  In  the  PTDE  Version  3  SAS  architecture,  the 
client  task  (MCE)  sends  an  ITC  message  to  one  or 
more  of  the  event  handler  tasks  which  in  turn  behave  as 
servers.  These  tasks  subsequently  perform  the 
requested  processing,  optionally  upidate  displayable 
database  items,  and  return  a  response  message  to  MCE 
upon  completion.  The  response  message  contains 
status  information  and  optional  algorithm  processing 
results. 

In  the  Ballistic  Missile  Defense  (BMD)  application,  the 
server  tasks  are  typically  models  of  individual  sensor  or 
weapon  systems,  or  in  some  cases,  specific  platforms 
within  a  sensor  or  weapon  system  because  simulation  is 
a  fundamental  component  of  the  battle  management 
process.  For  example,  evaluating  the  BMD  system's 
probability  of  negating  a  missile  attack  involves  using 
some  sort  of  model  to  simulate  balli.stic  missiles,  sensor 
systems,  and  weapons  systems.  Likewise,  evaluating 
candidate  engagement  opportunities  invariably  involves 
modeling  specific  ballistic  missile  trajectories  and 
weapon  platform  physical  characteristics  (such  as  orbits 
and  end  game  capabilities).  The  general  guidelines  that 
we  used  to  create  tiiis  software  architecture  skeleton  are 
suitable  for  application  in  any  comm.and  center  appli 
cation.  The  notion  of  a  creating  a  top  level  control  task 
and  partitioning  the  number  crunching  functions  into 
separable  NAS  application  tasks  is  generally  applicable 
to  any  command  center  application.  It  is  also  useful  to 
be  able  to  allocate  the  external  simulation  processing 
functions  to  separate  tasks  in  order  to  easily  be  able  to 
move  them  into  external  processors.  This  will  make  it 
possible  to  more  accurately  observe  the  performance 
characteristics  of  the  main  command  center  processing 
equipment  by  putting  the  external  simulation  process¬ 
ing  in  separate  processors. 

User  Interface.  The  basic  principles  of  providing  soft¬ 
ware  developers  with  higher  level  abstraction  supported 
by  text  file  driven  tools  that  generate  the  Ada  source 
code  were  also  used  in  the  User  Interface  functional 
area  on  the  CCPDS-R  project.  The  primary  user  intei- 
face  on  CCPDS-R  was  a  workstation  constructed  out  of 
a  DEC  Microvax  processor  which  drove  a  graphics 
processor.  The  choice  of  this  hardware  was  effectively 
dictated  by  the  end  user's  interactive  graphics  respon¬ 
siveness  requirements.  The  hardware  was  chosen  in 
1987,  before  the  emergence  of  the  texlay's  high  speed 
workstations.  One  of  the  goals  of  the  PTDE  develop¬ 
ment  was  to  replace  the  CCPDS-R  workstations  with  a 
functionally  equivalent  capability  based  on  X-windows. 
The  primary  reason  for  this  objective  was  to  achieve 
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Figure  6;  Impicmcnling  User  Interfaces  With  Display  Builder 


the  device  independence  to  take  advantage  of  future 
inexpensive,  high  performance  workstation  technology, 

T  he  design  of  the  u.scr  interface  for  C’  systems  is  tradi¬ 
tionally  a  long  and  difficult  activity  involving  interac¬ 
tion  and  concurrence  among  repre:x:ntativcs  of  the  end 
user,  system  engineering,  human  factors,  and  software 
development  communities.  It  invariably  includes  it¬ 
eration  on  the  layout  of  user  interface  screens  and  pro¬ 
totypes  of  their  operation  when  integrated  with  appli¬ 
cation  processing.  It  was  therefore  necessary  to  include 
a  rapid  user  interface  prototyping  facility  as  part  of  the 
PTDE  The  PTDE's  display  builder,  illustrated  in  Fig¬ 
ure  6  uses  serftware  that  had  been  developed  on  earlier 
user  interface  IR&D  projects.  It  supports  user  interface 
design  iteration  by  providing  a  way  to  rapidly  build 
both  display  prototypes  (graphical  rcpre.scnl3tions  of 
the  way  user  interaction  screens  will  lottk)  and  inter¬ 
active  application  prototypes  (executable  Ada  source 
ctxle  that  implements  a  complete  set  of  interactive  dis¬ 
plays  including  underlying  user  interaction).  The  bc.sl 
way  to  explain  this  point  is  to  step  through  the  PTDE's 


user  interface  design  pnKess  with  an  empha.sis  on  the 
role  of  the  PTDE's  display  builder  tool. 

The  first  step  in  designing  the  u.scr  interface  is  the  hu¬ 
man  engineering  step.  This  involves  analysing  the 
overall  mission  requirements,  the  command  centers 
operational  concept,  and  the  applicable  human  factors 
standards  that  must  be  incorporated  the  u.ser  interface. 
The  output  of  this  step  is  the  definition  cf  the  require¬ 
ments  on  the  human  interface  implementation.  These 
requirements  include  the  definition  of  the  complete  set 
of  user  interaction  screens,  the  information  content  of 
each  screen,  and  the  interaction  mechanisms  (such  as 
menus,  forms,  pickable  items,  etc.)  that  must  be  avail¬ 
able  on  each  screen.  The  PTDE  docs  not  provide  any 
specific  tools  to  support  this  activity.  It  is  primarily  an 
analytical  process  as  opposed  to  a  .software  develop¬ 
ment  activity.  However,  the  output  of  this  step  is  the 
input  to  the  di.splay  prototype  development  process. 

The  u.scr  interface  implementor  uses  the  PTDE's  di.s¬ 
play  builder  to  interactively  create  an  applications 
complete  user  interface  (such  as  the  hierarchy  of  win- 


dows  including  all  the  background  maps,  tabular  dis¬ 
play  layouts,  pull-down  menus,  etc.).  The  display 
builder  automatically  generates  the  needed  internal  rep¬ 
resentations  such  as  Ada  source  code  and  the  internal 
data  structures  that  are  used  by  the  workstation  soft¬ 
ware  to  perform  display  generation  when  the  applica¬ 
tion  runs  in  the  operational  environment.  The  display 
implementor  works  with  a  set  of  high  level  abstract 
objects  called  "widgets".  The  PTDE's  widget  set  is 
based  on  standard  Motif  widgets  including  pull-down 
menus,  pushbuttons,  toggle  buttons,  and  radio  buttons. 
It  is  a  general  purpose  widget  set  which  also  includes 
some  missile  defense  specific  windows  for  use  as  map 
backgrounds  and  annotation  symbols.  The  display  im¬ 
plementor  needs  only  to  learn  the  semantics  of  these 
widgets  because  the  PTDE’s  tools  hide  much  of  the  un¬ 
derlying  graphics  implementation  system  (in  this  case 
X-windows  and  Motif  toolkits).  The  PTDE's  display 
builder  is  actually  just  another  application  built  on  top 
of  a  general  purpose  interactive  application  framework. 
In  this  case  the  application  is  to  prototype  interactive 
user  interfaces  as  opposed  to  performing  interactive 
command  and  control.  The  display  builder  generates 
Ada  source  code  and  resources  database  necessary  to 
mpile  and  run  the  operational  version  of  each  appli¬ 
cation  it  creates.  It  also  generates  a  text  file  description 
of  the  application  which  can  be  used  to  port  an  appli¬ 
cation  to  some  other  hardware  environment. 

The  display  prototypes  arc  generally  used  to  review  and 
attain  concurrence  on  display  layout  details.  Modifying 
displays  based  on  user  comments  can  usually  be  ac¬ 
complished  in  a  matter  of  minutes  using  the  PTDE's 
display  prototype  building  capabilities.  User  interac¬ 
tions  can  be  checked  out  using  a  display  builder  test 
mode  which  allows  one  to  step  through  the  menu  tree 
and  exercise  an  application's  various  buttons  and  forms. 
Application  specific  processing  is  not  available  at  this 
point  in  the  process.  Once  concurrence  on  the  look  and 
feel  of  the  an  application's  user  interface  is  achieved, 
the  next  major  step  in  the  process  is  to  build  the  appli¬ 
cation  prototype.  The  application  prototype  is  based  on 
a  standard  Ada  process  main  program  that  executes  in 
the  workstation  during  on-line  command  center  opera¬ 
tion  (indicated  as  the  "Application"  in  Figure  6).  This 
program  contains  the  main  application  event  handler 
augmented  to  handle  additional  external  events  includ¬ 
ing  the  arrival  of  PTC  mes.sages  from  a  network  of  NAS 
application  programs.  The  PTDE's  user  interface  im¬ 
plementation  facility  generates  the  source  code  for  a 
skeleton  of  this  program  for  an  entire  application  which 
includes  stubs  for  the  application  specific  call  back 
events.  This  approach  is  analogous  to  the  way  in  which 
the  SAS  builder  tools  automatically  generates  Ada 


source  code  for  the  complete  set  of  processes  for  a  NAS 
network.  Of  course,  the  application  developer  must  re¬ 
place  the  stubs  with  appropriate  application  specific 
processing  for  call  back  events  such  as  menu  picks  and 
form  entries.  This  is  analogous  to  the  ITC  message 
handling  procedures  that  are  the  plugged  into  a  N.AS 
based  software  architecture  skeleton.  The  key  point 
here  is  that  the  PTDE  provides  the  capability  to  auto¬ 
matically  generate  all  the  display  system  related  source 
code  (including  application  call  back  stubs)  for  an  en¬ 
tire  interactive  application  that  interfaces  with  a  NAS 
network.  The  system  includes  an  Ada  graphics  library 
which  allow  the  application  developer  easily  perform 
any  additional  application  specific  graphics  pro¬ 
gramming  that  may  be  required. 

Conclusion  and  Recommendations 

The  Version  3  demonstration  included  a  simple  BMD 
application  that  included  23  new  external  messages.  13 
new  internal  databa.se  objects.  3  new  mission  proce.ss- 
ing  algorithm  procedures,  and  a  user  interface  consist¬ 
ing  of  29  new  displays.  It  contained  over  KXl.CXX)  new¬ 
lines  of  Ada  source  code.  The  demonstration  was  de¬ 
veloped  and  integrated  over  a  four  month  period  by  a 
team  of  five  people  who  also  produced  user  level  and 
interface  description  documentation.  The  software  de¬ 
velopment  productivity  experienced  on  this  project  Is 
superior  to  other  projects  performing  comparable  de¬ 
velopment  without  the  benefit  of  comparable  tools. 

The  PTDE  development  project  was  completed  by  the 
end  of  March,  1991.  The  development  team  is  cur¬ 
rently  continuing  to  develop  and  use  these  tools  and 
techniques  on  a  command  center  development  project 
using  PTDE  technology  for  the  USAF's  Space  Com¬ 
mand  in  Colorado  Springs.  Recently  implemented 
enhancements  to  the  PTDE  ba.scd  system  include: 
migration  to  the  next  generation  of  NAS  (called  UNAS 
[Royce  1991a.b])  for  improved  vendor  independence 
and  portability,  performance  enhancements  in  the 
dalaba.se  management  area,  and  new  di.splay  builder 
capabilities.  The  display  builder  is  currently  being 
used  by  Air  Force  personnel  to  design  the  user 
interfaces  on  the  new  project. 

The  PTDE  development  effort  has  provided  a  valuable 
opportunity  to  work  with  new  technology  that  can  sub¬ 
stantially  improve  the  productivity  of  the  command 
center  development  process.  The  most  important  les¬ 
son  learned  is  the  value  and  feasibility  of  using  au¬ 
tomation  to  enhance  Ada  software  development  pro¬ 
ductivity.  The  PTDE  development  team  started  with 


homemade  tools  that  were  inherited  from  the  CCPDS-R 
program  and  enhanced  them  by  adding  better  user  in¬ 
terfaces.  The  tools  generally  handle  the  mundane 
chores  necessary  to  nianage  the  declarative  part  of  a 
complex  system.  For  example,  the  SAS  builder  tool 
deals  with  the  static  declaration  of  a  task  network's 
topology,  the  CMT  deals  with  the  static  declaration  of 
external  message  set  attributes,  and  the  display  builder 
deals  the  user  interface  attributes.  Tools  of  this  nature 
are  not  hard  to  build.  The  original  tools  were  devel¬ 
oped  by  CCPDS-R  application  developers  for  their  own 
use  on  one  project.  They  were  not  called  out  as  con¬ 
tract  deliverables.  Their  spartan  nature  is  a  result  of  the 
fact  that  there  is  no  room  for  anything  else  in  a  cost 
constrained  development  program.  The  PTDE  devel¬ 
opment  gave  us  a  valuable  opportunity  to  enhance  the 
existing  tools  for  more  general  usage.  The  task  is  by  no 
means  complete.  Using  homemade  tools  naturally  gen¬ 
erates  more  ideas  for  enhancements. 

The  homemade  approach  to  tool  building  that  we  used 
is  not  the  only  way  to  apply  these  ideas  today.  There 
arc  many  currently  available  commercial  products  that 
one  could  u.se  accomplish  the  same  ends.  We  looked  at 
niatives  for  implementing  the  display  builder 
and  settled  with  the  homemade  approach  for  its  flexi¬ 
bility,  performance,  and  ability  to  support  producing  all 
Ada  applications.  Organizations  not  having  an  equiva¬ 
lent  legacy  would  be  likely  to  find  a  COTS  based  ap¬ 
proach  preferable  for  their  needs. 
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